1. Field of the Invention
The present invention relates generally to objected-oriented systems and, more particularly, to projection of full featured business objects.
2. Description of the Related Art
There is, and will continue to be, advances and changes in how enterprises conduct business. Whether these advances and changes occur through growing competition and globalization, mergers and acquisition, or a revamping of business models, the key for success will often depend on how quickly the enterprise's information technology (IT) organization can adapt to evolving business needs. Therefore, a major challenge to these enterprises is how they handle change.
For organizations to enable business agility, they must ensure that enterprise applications are not only high-performance business engines driving efficiencies, but also that they become flexible building blocks of future business systems. A recent promising solution has risen in the form of services. A service, such as a Web service or program, represents a self-contained, self-describing piece of application functionality that can be found and accessed by other applications. A service is self-contained because the application using the service does not have to depend on anything other than the service itself, and self-describing because all the information on how to use the service can be obtained from the service itself. The descriptions are centrally stored and accessible through standard mechanisms.
Instead of requiring programmers to establish and maintain links between applications, services are loosely coupled, making connections simpler and more flexible and allowing application architects to more easily find and understand services offered by other cooperative applications. However, the problem that exists with services is that they are often designed to expose functionality of individual applications and thus are too limited to be efficient building blocks for enterprise-wide business processes. A solution to this shortfall has been the migration to a Service Oriented Architecture (SOA). The SOA is an open architecture middleware, which builds on the benefits of services. An example of an SOA can be found in the Enterprise Service Framework (ESF), which is commercially available from SAP AG, Walldorf, Germany. The term “SOA” may also be used to refer to “distributed objects” architecture, such as CORBA (Common Object Request Broker Architecture) and DCOM (Distributed Component Object Model).
The SOA enables the abstraction of business objects, modeled as services (also referred to as enterprise services), from actual applications. Aggregating services into business-level enterprise services may provide more meaningful building blocks for the task of automating enterprise-scale business scenarios. Enterprise services allow IT organizations to efficiently develop composite applications, defined as applications that compose functionality and information from existing systems to support new business processes or scenarios.
The SOA also enables the use of an enterprise services repository. The enterprise services repository stores relevant pre-existing enterprise services and makes them available to selected partners and customers. By using the enterprise services repository, these selected partners and customers can use the pre-existing enterprise services to aid in the implementation of new services and corresponding business objects. The term business object represents a physical or logical object of significance to a business, such as a purchase order. An “object” refers to a software bundle of variables (e.g., data) and related methods. For example, in object-oriented programming, an object is a concrete realization (instance) of a class that consists of data and the operations associated with that data.
Object-oriented development may provide applications (e.g., Web services, software applications, software components, software modules, software entities, and the like) with flexible building blocks, or “objects,” of enterprise business systems. Such flexible building blocks allow developers to reuse class libraries in other applications for potentially different tasks without the need to duplicate work.
In a service framework (e.g., ESF) that includes service entities, a client can “call” a service entity from a service entity provider through an Application Program Interface (API). As used herein, the term “service framework” refers to a defined support structure in which software systems and applications, such as Web services, can be developed, organized, compiled, deployed, customized, run, and/or executed. A service framework may include computer hardware, computer networks, user interfaces, support programs, code libraries, code repositories, scripting language, or other components to help develop and glue together the different components of one or more software systems or applications. The service entity provider allows the instantiation of business objects in response to the API call. As used herein, the term “instantiate” means, in an object oriented programming (OOP) environment, to allocate in memory or other suitable location, an object of a particular class, and, more generally, may include deploying, customizing, running and/or executing an application.
Business objects are frequently utilized in conjunction with other business objects based on relationships between the objects. For example, in the real world, a person may have a name and a home address. Business objects may model this as a person class with a name field and an address class including fields for address information separate from the person business object. The address object may be said to be “linked” or “related” to the person object. Design and development of business objects typically requires significant time in order to accurately model and perform such real-world business processes, particularly more complex scenarios. The complexity of business object development may be increased significantly when a business object must function in multiple roles within an application or applications.
Many business objects may be utilized in multiple roles. FIG. 1A depicts one exemplary scenario where a single business object may be useful for many different roles. For example, a person modeled as a contractor for a company may also appear as an employee of that company (he works for the company), a supplier to the company, and a customer of the company (e.g., where the person also purchases from the company). The different roles share common data such as the person's name and telephone number, but the person object also has multiple role specific data. For example, data associated with an hourly rate for a contractor may be important in the person's capacity as a contractor (i.e., a supplier to the company), but such data may be substantially irrelevant in the person's capacity as a customer of the company.
Business objects that associate with other objects typically utilize different relationships based on the current role in which the business object is functioning. For example, the person above acting in a contractor role may have an association to a contract object containing the terms of the contract. In another example, the person acting in a capacity as a customer may be associated with multiple transactions for goods and services. In both examples, the data for the person remains the same, but the role related data may differ substantially. Because a single instance of a business object may be required to function in multiple roles concurrently within the same user interface, business object design may become a confusing scenario for a user attempting to craft a reusable object architecture.
In addition to role related data, behaviors of business objects may vary depending on the role in which they are functioning. For example, the algorithm used to check the validity of a contractor's contract terms may be different from the logic used to check a purchase order for a customer. In another example, queries used to insert contract data into a database may, and likely will be, completely different from those used to insert records related to purchased goods. This may lead to further confusion and difficulty for an architect attempting to create a reusable object architecture.
Implementation of business objects in such varying roles has typically led to a user developing multiple business objects with functionality and data related to a particular role. For example, a person acting as a contractor for a company may be modeled within a “contractor” class. That same person acting as an employee of the company may be modeled within an “employee” class, yet in both examples, the person is still a person acting in different roles. Such design can lead to substantial confusion and additional work when trying to model business processes within the SOA.
Further, substantial design and programming skills have been required to adequately model and code business objects for use in particular enterprise systems. When designer and programmer resources are being utilized for other projects, it may slow the development of other critical systems.
In the view of the foregoing, there is a need for systems and methods that assist users working within an SOA to efficiently utilize reusable business objects to model enterprise wide methodologies. Further, there is a need to simplify the architecting of such systems within an SOA such that users with minimal programming and development skills may model and create an enterprise system without compromising the flexibility of reusable objects.
The present disclosure is directed at overcoming one or more of the problems or disadvantages discussed above.